Byte 9 is the checksum and it's Ok for all values CRC = ( Byte1 + Byte2 + Byte3 + Byte4 + Byte5 + Byte6 + Byte7 + Byte8) mod 256
Example 40
0 + 75 + 169 + 0 + 1 + 0 + 2 + 16 + 7 = 270
270 mod 256 = 7
Checksum = 7

Hi Joakima,
Thanks for jumping into solving this :)
Yes, byte 9 is checksum which is calculated as the addition of bytes 1 thru 8.
I also tried using Byte 6 as multiplier but I think the algorithm is non linear.
Thanks

Hello all,

I've managed to get a stable ASM version for a 16F876A that reads the values from the Efergy E2 meter.

First things first:
- I'm using a E2 meter, not an elite.
- the transmission starts with some garbage things (high/low without any meaning), followed by a LOW period, two short bursts of HIGH, then anoter long LOW period then a HIGH for 500ms precisely
- after this, the data gets transmitted (in my oppinion at least)
- I can confirm, 1 or 0 is described as in this article, not as in Joe's meter (http://jdesbonnet.blogspot.com/2010/09/smart-electricity-meter-based-on-efergy.html). I think they've changed the protocol...
- I've considered a 500ms pause as the beginning of the transmission.
- I don't think converting into decimal is a good idea. I'll detail on that later
- 4 bytes at the start are repeated no matter if the meter is set to 6,12 or 18s. Or that it reads 0 or 10kW
- at the end there's some garbage (transmitter shutting down??)

The data structure as I see it:
- first byte: SYNC : 00000001 in my case (1 as decimal)
- secondL SYNC: 00010001 in my case (174 as decimal)
- third SYNC. : 11011100 in my case (220 decimal)
these first three bytes the same in my case
- fourth: some data, including the interval:
10100000 for 6s
10101000 for 12s
10110000 for 18s
- fifth: actual data
- sixth: data
- seventh: data
- eigth: data (with some garbage at the end possibly)

Now, some values for 4,5,6,7,8 byte, 230v as reference
_10100000_00000000_00000000_00000000_00101100 =0W, 6s
_10101000_00000000_00000000_00000000_00110100 =0W, 12s
_10110000_00000000_00000000_00000000_00111100 =0W, 18s

comment continues below

so, byte 5,6,7,8 are relevant for the data (or is it a checksum?)... I say 8 also, because the bit from the left (0 in all of the samples above), gets 1 in some cases...


let's get some values for 230v (columns: byte5,byte6,byte7,byte8, actual reading):
00100001 11101011 10000000 00111001 121
00110010 10001111 00000000 01101110 181
00110101 11000010 10000000 00100100 193
00110110 01100110 00000000 01001000 195
00110011 11010111 00000000 00110100 195
00110111 00001010 00000000 01101101 197
00110111 00001010 00000000 01101000 197
00110111 00001010 00000000 01101101 197
00110101 00011110 10000000 00000000 197
00110101 00011110 10000000 00000000 197
00111010 00111101 00000000 00100011 209
00111011 10000101 00000000 01101101 213
00111101 01110000 10000000 01011010 220
00100000 00000000 00000000 11001101 229
00100000 01010001 10000000 10011110 232
00100000 01010001 10000000 10011110 232
00100000 10100011 10000000 11110001 234
00100000 11110101 10000000 11000011 236
00100010 00111101 00000000 10001100 246
00100010 11100001 00000000 10110000 250
00100011 00110011 00000000 10000011 252
00100011 10000101 00000000 11010101 255
00100110 10111000 00000000 10001011 278
00100111 00001010 00000000 11011110 280
00101001 00101101 00000010 00000100 2367
00101010 10010110 10000010 01101111 2448
00101010 11010010 10000010 00101011 2462
00101011 00001111 00000010 01101000 2475
00101101 10100101 10000010 00000001 2624
00100001 11100000 00000010 10110000 3895
00100010 10100000 00000010 11000000 3909
00100010 00100000 00000010 11110001 3924
00100010 11100000 00000010 10110001 4010
00100010 11100000 00000010 10110001 4010
00100011 00100000 00000010 11110010 4039
00100011 11100000 00000010 10110010 4125
00100100 00000000 00000010 11010011 4139
00101000 10100000 00000010 11110111 4671
00101000 11000000 00000010 10010111 4685
00101000 11100000 00000010 10110111 4700
(continues below)

00101001 00000000 00000010 11011000 4714
00101001 11000000 00000010 10011000 4800
00101010 00100010 00000010 11111011 4845
00101010 00000000 00000010 11000000 4845
00101100 11001100 10000010 10101000 5151
00101110 01100110 00000010 11000011 5335
00100010 01000000 00000011 00010001 7877
00101101 00000000 00000011 01011100 10340
00101101 00000000 00000011 01000000 10340

What I can offer:
- the ASM for the PIC. It's a pretty fancy version of a PIC, clocked at 20Mhz, external XTAL, etc... It outputs @9600,8,N,1 the data in decimal form.
- a .net windows form application that displays incoming data in binary form. Or in decimal if you like. Sources provided if interrested (Visual Studio Express is free...)

What I would like to have:
- some kind of logic for the numbers above. How they are calculated...

If someone gets the sense of all this, I intend to write a ASP.net website that monitors in realtime the data & stores it for further analysis.
I'm pretty confident that we will get this solved very very very soon.

sorry for the typos, it's quite late...

even simpler:
what's the relationship between
17367 (01000011 11010111) with factor/multiplier/exponent/etc(?) 0 (00000000) and 124W @230V
21299 (01010011 00110011) with factor/multiplier/exponent/etc(?) 0 (00000000) and 149W @ 230V
28180 (01101110 00010100) with factor/multiplier/exponent/etc(?) 0 (00000000) and 197W
31457 (01111010 11100001) with factor/multiplier/exponent/etc(?) 0 (00000000) and 220W
and
17530 (01000100 01111010) with factor/multiplier/exponent/etc(?) 1 (00000001) and 246W
17858 (01000101 11000010) with factor/multiplier/exponent/etc(?) 1 (00000001) and 250W
19824 (01001101 01110000) with factor/multiplier/exponent/etc(?) 1 (00000001) and 278W

21805 (01010101 00101101) with factor/multiplier/exponent/etc(?) 4 (00000100) and 2448W
22046 (01010110 00011110) with factor/multiplier/exponent/etc(?) 4 (00000100) and 2475W
32384 (01111110 10000000) with factor/multiplier/exponent/etc(?) 4 (00000100) and 3636W

18496 (01001000 01000000) with factor/multiplier/exponent/etc(?) 5 (00000101) and 4153W
27275 (01101010 10001011) with factor/multiplier/exponent/etc(?) 5 (00000101) and 6125W

17536 (01000100 10000000) with factor/multiplier/exponent/etc(?) 13 (00001101) and 7877W
23040 (01011010 00000000) with factor/multiplier/exponent/etc(?) 13 (00001101) and 10340W

and we have the answer to the efergy e2 protocol....

Hello,

a quick upate: jdesbonnet cracked it based on this elements. The formula is, I quote:

W = V * (a / (2^15)) * (2 ^ b)

Or in C/C++/Java syntax:

power = volts * (a / 32768) * (1 << b)

where a = number, b = factor in the above data. There were some errors (13 should have been 6).

Alex,
Thanks a lot but the formula doesn't seem to work with my values...
Will re-check
Jose

Yes it does, let's take an example:
17530, factor 1.
230 * (17530/32768)*(2) = 246.087
(reading: 246 on the screen)

27275 factor 5 =
230 * (27275/32768)*2^5 = 6126.220W (6125W displayed)

and so on. There was a mistake on my last number exponent (13) which should read 6.

I can confirm it's pretty accurate, I have it running on my laptop as I speak. Will test right away with > 10kW power to see.

Joe really is the best!

I declare it officially cracked!

Let me know how I can post the .ASM file for the PIC, & so on. FOr the time beeing I have the windows application running (.net). Tomorrow wil start the work on the website (which will certainly evolve over time).

PIC file and Winform application posted in files! sorry for the excitement but I'm quite happy.

That's definitely different from my readings...
thanks anyway!

0w No Clamps Led 40w 60w 100w 600w 800w 1860w 2180w 2960w 3060w 4230w
Data 1 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000
Data 2 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011 75 01001011
Data 3 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001 169 10101001
Data 4 0 00000000 128 10000000 0 00000000 0 00000000 0 00000000 128 10000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000
Data 5 1 00000001 1 00000001 1 00000001 1 00000001 1 00000001 1 00000001 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000
Data 6 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 0 00000000 16 00010000 16 00010000 16 00010000 16 00010000 32 00100000 32 00100000
Data 7 2 00000010 2 00000010 2 00000010 2 00000010 2 00000010 2 00000010 1 00000001 1 00000001 1 00000001 1 00000001 1 00000001 1 00000001 1 00000001
Data 8 Current 8 bits 0 00000000 0 00000000 2 00000010 16 00010000 24 00011000 39 00100111 243 11110011 38 00100110 172 10101100 201 11001001 253 11111101 11 00001011 75 01001011
Data 9 Checksum 247 11110111 119 01110111 249 11111001 7 00000111 15 00001111 158 10011110 232 11101000 43 00101011 177 10110001 206 11001110 2 00000010 32 00100000 96 01100000
Checksum 247 11110111 119 01110111 249 11111001 7 00000111 15 00001111 158 10011110 232 11101000 43 00101011 177 10110001 206 11001110 2 00000010 32 00100000 96 01100000

Jose,
try using the provided PIC software & the windows forms application. I've tested it during the last hour for values between 160w (as low as I get here) and 13.000W. And it is bang on, except sometimes for 1-2W difference. Absolutely bang on.

I can attest to the fact that counting the pulses by hand gave me some errors at first (errors due to eye strain, fatigue, etc).

addition:
if power <110w (approx) and the exponent is 11111111 (this comes in...) than the formula should be -1 instead of e.

I hope they don't have x protocols for x devices..

@Alex and Joesito, Read your great post and would like to know how to extract information from efergy E2 RX to Arduino so that I can pass it onto pachube online.

If there is a known point on the Rx E2 that I can feed that into a microprocessor like Arduino and calculate KWh ? (Arduino is already on internet through LYNKSYS 54GL wireless router hack on serial port passing data to pachube as we speak for solar temp measurements id 24922).

Other way is to use CT sensors and write Arduino logic but it seems pointless when the E2 is displaying the values and is Wireless so no wire needed between CT and Arduino.

I prefer your solution of tapping into the Rx data using the formalue. I would just need to know exactly where to connect I guess a GND and and a digital line from the Arduino as Input to E2 dataout ( line 18 on the chip or is there a better point since it looks tight ? ).

Can you also advice as to how I process the incoming data from the E2 and what delays I need to create in order to syncronise with the data an what to discard and what to keep and finally I guess apply to the formulae above !!

Any help welcome

Regards

Jean

Hello Jean,

please visit Joe's website (last link, see above), you'll get a pretty good picture of the place you should use for wiretapping. For GND you can use the black wire that comes from the battery.

Oh, just one thing: the pulse is VERY short (70uS), I don't know if the Arduino can be triggered that fast. Before the PIC solution, I've tried a FEZ Domino, clocked @ 72Mhz (but with the .net micro framework overhead) and it couldn't keep up.

I think speedwise the Arduino can handle down to Microsecond resolution and found a example measuring the pulse of an IR remote using an Arduino and a sensor which is about good enough at this link http://www.ladyada.net/learn/sensors/ir.html letme know if you think its worth a go ?

I can give it a try if you point me in the right direction as far as decoding the data and picking off the right bits.

Tell me the delays and what to lookout for then I can try and get a sample code together.

Thanks so far for your help.

Jean

Hi Alex I Found this http://www.arduino.cc/en/Reference/PulseIn which might give us a start. says it can read down to 3us.

If I solder a wire from 18 on the chip and wire up to ground on Arduino lets see what I get !!!!

Jean

how did you get inside the E2 Rx without damaging it ?

the idea is the following:
- the transmission starts with some garbage, followed by a rather long LOW pulse.
- a precisely 500ms HIGH pulse follows.
- then it's 1 and 0, 8 bytes.
- the 1 is a _|---| (see Jose's drawing please)
- the 0 is a __|-|
- throw that on a serial port and use the Windows forms application. Normally it should read (according to the formula) the real value.

+

The front screen is glued with double tape if I remember correctly. After it comes off, you have access to some set of screws. It was a while ago when I took it apart (almost a year)...
Afterwards I've exposed the +,- and data line with some female headers outside the case (made a small incision to pass them through the case). Then put it back.
That way you can tap on the lines & have the case (almost) intact.

OK I thought I could see the screw holes in the front behind the border so I guess its time to hack it open !!!

Can I just expose data line and GND since the digital input to arduino will measure voltage I assume HIGH 3.3V low 0V ?

Also what simple algorithm worked best for U ?I guess something like wait for long high pulse (500ms you mentioned (E2) graph shows 1000ms (ELITE)) then grab 8 bytes or 72 bits (including checksum) at known intervals or until some condition ?

do I need to set a Baud Rate up from the digital in Side that matches E2 or should I just read bytes ? ( I have never done this before and have no experience of reading digital data but it cant be too dificult !) if you have a script in PIC or another language I can try and make sense of it to get an idea of what you did.

In the end an Arduino version would be cool for the community so im prepared to help out but probably need to ask Arduino Forum how I should go about it. you could provide me with the simple steps required and I can work out how to do it.

So how do you syncronise and repeat the above steps you have given me to achieve data changes at 6sec intervals ?

Ill open the case tomorrow !!!


Jean

wow look forward to giving that a go Ill keep you posted !! I think its a fantastic solution although may not be altogether accurate given that we are guessing the voltage (in my case 110V in Costa Rica) but at least I have a reference display to calibrate and also its cool that no wire is needed between fusebox and display since data is collected at the display which means you can have it all in a dryer place. for my purpouse just to have the data online is fine it doesnt have to be super accurate as long as I can see activity like when a pool pump is running or AC units or if the dryer is on when I´m back in UK.

int E2Pin = A5; // Digital Input Pin allocated to E2 output
int E2Bytes = 8; // bytes of data required
int pulseDUR = 200; // pulse duration of data in usecs
int leadHIGH = 500; // lead HIGH duration in usecs
long longLOW = 500000;// long LOW duration in usecs before leadHIGH
boolean DataIN = LOW;// flag to determine when to collect dataIN
boolean pauseLOW = LOW;// flag to determine of pauseLOW period has occured
boolean E2pulse; // pulse of data reived from E2
//pulseIn() used here to our benefit
//Reads a pulse (either HIGH or LOW) on a pin. For example, if value is HIGH, pulseIn() waits for the pin to go HIGH,
//starts timing, then waits for the pin to go LOW and stops timing. Returns the length of the pulse in microseconds.
//Gives up and returns 0 if no pulse starts within a specified time out.
//The timing of this function has been determined empirically and will probably show errors in longer pulses.
//Works on pulses from 10 microseconds to 3 minutes in length.

//Syntax

//pulseIn(pin, value)
//pulseIn(pin, value, timeout)

// main loop starts here

void setup()
{
pinMode(E2Pin,INPUT);
DataIN = LOW;
pauseLOW = LOW;
}

void loop()
{
E2pulse = digitalRead(E2Pin); // get à value of E2 Digital Pin

if (E2pulse == HIGH) {
if ( pulseIn(E2Pin, HIGH) >= leadHIGH) { // see if we have reached start of data
if (pauseLOW == HIGH) { // only set ready to accept reading data if pauseLOW has passed
DataIN = HIGH;
}
} // else ignore and go round again
}
else { // pulse is LOW check if short or long
if ( pulseIn(E2Pin, LOW) >= longLOW) { // skip the long low period
pauseLOW = HIGH;
}
}

if ( DataIN == HIGH ) { // time to collect the get the data we want
get_next_nbytes ( E2Bytes+1, pulseDUR);
// send data here if we want
DataIN = LOW; // reset vars
pauseLOW = LOW;
}
}

// function to read next nbytes at Cycle microsecond intervals
void get_next_nbytes(int Nbytes,int Cycle);
{
delayMicroseconds(Cycle/2) // delay a 1/2 cycle to be bang in middle of pulse
for (Byte = 1 , Byte <= Nbytes , Byte++) {
for (Bit = 1 , Bit <= 8 , Bit++) {
data_array[Byte][Bit] = digitalRead(E2Pin); // store value in array
delayMicroseconds(Cycle) ; // delay to land in the middle of each bit
}
}
}

sorry the above was not formatted with indents its just a skeleton for you to look at

Jean

There is no need to test your soldering skills that much I put a meter on continuity and there is actually a test point to pin 18 (see diagram above) 3mm above pin 20 that silver round disc is connected to pin 18 ;-). ok time to make the socket !!!

Just a sidenote:

I finished the website for the efergy.
It stores all of the incoming measurements into a database. The meter samples every 6s. I expect the database to be rather large after two years, but for the time beeing, my small 500mhz pico-itx computer handles it very well.

The shock (and the reason for this post) is that the total for a day (and I suspect for a month, will confirm that after a month period) shown by the meter, by pressing the history button, is miscalculated. Not by 1-3watts/h, but by a rather astonishing figure: 1KWh.
I saw a difference today (the first day with a day long logging session in place).

First thing I did, I rechecked my calculation. No complex math involved, so should be pretty obvious. Then I noticed that some samples were missing (1168 out of 14.400 for 24h if the interval is 6s). So I've replaced the missing samples with the reading just before the missing package. Still, the difference is quite large
- calculated data based on the incoming readings : 5.96KWh for today,
- meter shows total for today 6.99KWh.

I triple checked (by adding the values in the database, by adding them in C# code, etc), no rounding, no nothing.

I pretty much suspect they're wrong with the meter, because in the database I pretty much have the same thing that was shown on the screen of the meter...
As soon as more data will be logged, I hope to get a better picture of the problem. But I suspect it's not in my code.

Good night
alex

intresting observation good work !! I have wired up as per the diagram but dont get to see much data until i disconnect and reconnect the dataout line , Im not able to make much sense of what is incoming at this time and the databusrts seem to be sporadic , Im sure the arduino can handle down to 5us cycles so seeing data even polling at 200us intervals you would think you see something but no luck, could it be the earth connection ? I have writen a simple logic analizer that looks for change of state and logs in microseconds how long they lasted but it wont trigger unless I disconnect and reconnect the pin18 link and then doesnt continue to flow. I was hoping to see the long low of 500ms and the short high of 500us but nothing like that. shame to have got this far and give up so any ideas ?

I would suspect you're driving high the pin output, instead of having it as an input.
If you leav the arduino connected for a long(er) time, does the efergy meter still receives valid data or does the screen go "- - -"?

Like I told you, for debugging purposes a Logic Analyzer (like the Saleae for ex) would be a very good choice. I really can't help without having an idea of what's going on.
You could test your "logic analyzer" software by plugging it on a function generator (a soundcard maybe?).

I had no luck extracting digital data from pin18 dont know what the reason is but kinda giving up for now... would it however be possible to find a point on the Tx that Yelds a voltage proportional to the current consumption without affecting the existing data it send the the Rx ? Reason for asking is I still want to use the existing CT clips to measure my house consumption but just want to "tap in" to the Tx. Once I have this proportional voltage I can scale it up and calibrate it to the match the readout on the display. Any help welcome.

Has anyone looked at the Efergy Elite or E2 sold in North America. I have one of each and want to see if I can obtain data from them for energy logging and analysis. I think the only difference is that the N.A. version requires two (2) sensors connected to the transmitter instead of one (1). I would assume the data stream will carry twice the data.

Once I get access inside the Elite I will connect pin 18 to a logic analyzer to see what the data steam looks like, and if I can decipher it. If so, I will employ a PIC to decode it and transmit it via serial port to a TS7800 embedded computer that provides a number of related functions including controlling my wood boiler and heating system.

Any advise would be helpful. Thks!

I think the data output will still be the same. My guess is that the summed up value will be transmitted, even if you use 1,2 or 3 current sensors connected to one transmitter.
Nothing sure, but decoding things will not be that hard because:
- the PIC software outputs all of the 8 bytes that are transmitted
- you can swap the current sensor position in the transmitter jacks => see what changes

my 2c.

thanks alex

Having recently purchased an Efergy E2 in the U.S., I thought I'd take a crack at recording the detail of what the transmitter was sending using the information others have already provided. Since the Elink software doesn't go into the detail I need, I'm using the same tap into the receiver as described, and recording the information to an SDHD card using an Atmel ATMEGA328 MCU.

I ran into some difficulty in that Efergy apparently changed the protocol since the postings in 2011. What I'm seeing now is the same 500 microsend high level as the start of the data, but only 64 bits are now transmitted instead of 72 (or more). The transmission is sent high bit first. The first 3 bytes worth are the transmitter id. The fourth byte holds the interval, reading 0x40 for 10 seconds, 0x50 for 15 seconds, and 0x60 for 20 seconds. I'm guessing there's still a bit for the battery level in that byte. The last byte, number 8, holds the checksum in mod 256 format. Add bytes 1 through 7, do the mod 256, and you get byte 8.

Bytes 5 and 6 hold the primary amp level, with byte 5 as the high byte. Byte 7 is the factor for the calculation. To obtain the amperage, take the number from bytes 5 & 6 and divide it by 32768. Then multiply that by 2 raised to the number in byte 7. For example, if bytes 5 and 6 are 0x6a52 (27218 decimal), and byte 7 is 0x03, the calculation to get the amperage is (27218/32768)*2^3. The calculation hasn't changed from previous posts. To get your wattage, just multiply that result by the voltage. If byte 7 is 0xff, then the formula is (value/32768)*2^-1, aka (value/32768)/2.

The major change from the earlier comments is that the transmitter is sending 64 bits worth, or 8 bytes, versus the 9 that other people were seeing. The fourth byte, which has the interval, is also different. The math is still the same for recovering the amperage.

My late 2 cents worth.